Synchronization (argo)

gpt-5.icon

Argo Workflows の Synchronizationとは

複数の Workflow や Template が “同時に走りすぎる” ことを防ぐために、実行数を制御する仕組み（ロック） を提供する機能。

制御できる並列実行の範囲

1. Workflow 全体の並列実行数

2. Template（ステップ）単位の並列実行数

3. 1つの Workflow の中でのタスク数（parallelism）

ロックの種類

Argo ではロックのことを総称して “locks” と呼び、2種類ある。

その Workflow Controller 内だけで有効

コントローラ Pod が分散されていなければ、通常はこれで十分

mutex（排他） → 1個しか起動できない

semaphore → 指定数だけ並列実行可

semaphore の上限値は ConfigMap に設定

PostgreSQL / MySQL を利用

複数クラスタ・複数コントローラでロックを共有したい時に使う

DB を設定していないのに database lock を使うとエラー

Mutex と Semaphore の違い

table:_

種類 意味 例

mutex 完全排他。1つだけ実行したい 「決済処理は同時に1つだけ」

semaphore 上限数だけ実行可能 「ETL ジョブは3つまで並列可能」

Local Lock の使い方

Local mutex（Workflow 全体を排他）

code:yaml

spec:

synchronization:

mutexes:

- name: bar

Local semaphore（上限は ConfigMap）

code:yaml

data:

my-work-semaphore: "2" # 同時に 2 つまで実行可能

ConfigMap側は、これをセマフォの上限値として使用されることを知らない

Workflow 側

code:yaml

spec:

synchronization:

semaphores:

- configMapKeyRef:

name: my-config

Database Lock の使い方

Workflow 側（mutex）

code:yaml

spec:

synchronization:

mutexes:

- database:

key: bar

semaphore の上限値の設定（DB 手動操作）

code:_

INSERT INTO sync_limit (name, sizelimit) VALUES ('foo/bar', 3);

Namespace の扱い

ロックキーは namespace + key で一意に決まる

ConfigMap ベースの semaphore は ConfigMap の namespace も参照

DB ロックは namespace に実体がなくてもよい（global ロックが可能）

Workflow-level Synchronization

Workflow 全体の並列数制御。

ConfigMap ベースの semaphore（Example）

code:yaml

synchronization:

semaphores:

- configMapKeyRef:

name: my-config

key: workflow

mutex（＝ semaphore limit=1 相当）

code:yaml

synchronization:

mutexes:

- name: test

Template-level Synchronization

Template の同時実行数を制限。

Example（semaphore = 2）

code:yaml

templates:

- name: acquire-lock

synchronization:

semaphores:

- configMapKeyRef:

name: my-config

key: template

mutex（Template 単体を排他運用）

code:yaml

templates:

- name: acquire-lock

synchronization:

mutexes:

- name: welcome

Queue（待ち行列）の仕組み

ロックが取れない Workflow はキューに入る。

並び順：

1. priority の高い順

2. 作成時刻が古い順

複数ロックを必要とする場合は、全部取れるまでブロックされる。

Monitoring

Workflow のステータスで確認

.status.synchronization

Database を直接見る場合

code:sql

SELECT * FROM sync_limit; -- 上限

SELECT * FROM sync_state; -- 誰がロック保持/待ちか

SELECT * FROM sync_controller; -- コントローラの心拍

Database テーブルの概要

sync_limit

semaphore の最大同時実行数（ユーザーが INSERT）

sync_controller

コントローラの heartbeat（60秒ごと更新）

sync_state

どの Workflow がどのロックを保持/待ちか

sync_lock

複数コントローラ間のロック競合調停用

Controller が死んだ場合

heartbeat が更新されないと “inactive” と判定

その controller が保持していた pending lock は無視してよい

held lock（実際に握っていた） は自動解放されないので、

必要なら DB で手動削除する必要がある

よくある用途例

同じリソースを更新する Job を排他にする（mutex）

同時実行可能な ETL の数を制御（semaphore）

Template 単位で負荷をコントロール（Template-level semaphore）

複数クラスタ間でジョブの実行調整（database lock）